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Abstract 

Applicative functors ( 0 ) are a generalisation of monads. Both 
allow expressing effectful computations into an otherwise pure 
language, like Flaskell (QD). 

Applicative functors are to be preferred to monads when the struc¬ 
ture of a computation is fixed a priori. That makes it possible to 
perform certain kinds of static analysis on applicative values. 

We define a notion of free applicative functor, prove that it satisfies 
the appropriate laws, and that the construction is left adjoint to a 
suitable forgetful functor. 

We show how free applicative functors can be used to implement 
embedded DSLs which can be statically analysed. 

Categories and Subject Descriptors D.3.3 [ Programming Lan¬ 
guages ]: Language Constructs and Features 

General Terms Flaskell, Free Applicative Functors 
Keywords Applicative Functors, Parametricity, Adjoints 

1. Introduction 

Free monads in Flaskell are a very well-known and practically used 
construction. Given any endofunctor f, the free monad on f is given 
by a simple inductive definition: 

data Free f a 
= Return a 
| Free (f (Free f a)) 

The typical use case for this construction is creating embedded 
DSLs (see for example GU, where Free is called Term). In this 
context, the functor f is usually obtained as the coproduct of a 
number of functors representing “basic operations”, and the result¬ 
ing DSL is the minimal embedded language including those oper- 

One problem of the free monad approach is that programs written 
in a monadic DSL are not amenable to static analysis. It is impos¬ 
sible to examine the structure of a monadic computation without 
executing it. 

In this paper, we show how a similar “free construction” can be 
realized in the context of applicative functors. In particular, we 
make the following contributions: 
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• We give two definitions of free applicative functor in Flaskell 
(section|2]i, and show that they are equivalent (section|5j. 

• We prove that our definition is correct, in the sense that it really 
is an applicative functor (section [6]», and that it is “free” in a 
precise sense (section|7J. 

• We present a number of examples where the use of free ap¬ 
plicative functors helps make the code more elegant, removes 
duplication or enables certain kinds of optimizations which are 
not possible when using free monads. We describe the differ¬ 
ences between expressivity of DSLs using free applicatives and 
free monads (section[3]l. 

• We compare our definition to other existing implementations of 
the same idea (section[9]t. 

This paper is aimed at programmers with a working knowledge 
of Flaskell. Familiarity with applicative functors is not required, 
although it is helpful to understand the motivation behind this 
work. We make use of category theoretical concepts to justify our 
definition, but the Flaskell code we present can also stand on its 


1.1 Applicative functors 

Applicative functors (also called idioms) were first introduced in 0 
as a way to provide a fighter notation for monads. They have since 
been used in a vari ety o f different applications, including efficient 
parsing (see section |~i~4l i, regular expressions and bidirectional rout¬ 
ing. 

Applicative functors are defined by the following type class: 
class Functor f =4- Applicative f where 
(<*>)::f(a4b)^fa4fb 

The idea is that a value of type f a represents an “effectful” 
computation returning a result of type a. The pure method creates 
a trivial computation without any effect, and ( <*> ) allows two 
computations to be sequenced, by applying a function returned by 
the first, to the value returned by the second. 

Since every monad can be made into an applicative functor in a 
canonical way, the abundance of monads in the practice of Flaskell 
programming naturally results in a significant number of practically 
useful applicative functors. 

Applicatives not arising from monads, however, are not as 
widespread, probably because, although it is relatively easy to 
combine existing applicatives (see for example flol t. techniques 
to construct new ones have not been thoroughly explored so far. 

In this paper we are going to define an applicative functor FreeA f 
for any Haskell functor f, thus providing a systematic way to create 
new applicatives, which can be used for a variety of applications. 
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The meaning of FreeA f will be clarified in section^] but for the 
sake of the following examples, FreeA f can be thought of as the 
“simplest” applicative functor which can be built using f. 

1.2 Example: option parsers 

To illustrate how the free applicative construction can be used in 
practice, we take as a running example a parser for options of a 
command-line tool. 

For simplicity, we will limit ourselves to an interface which can 
only accept options that take a single argument. We will use a 
double dash as a prefix for the option name. 

For example, a tool to create a new user in a Unix system could be 
used as follows: 

create_user —username john \ 

—fullname "John Doe" \ 

—id 1002 

Our parser could be run over the argument list and it would return 
a record of the following type: 
data User = User 
{ username :: String 
, fullname :: String 
, id :: Int} 
deriving Show 

Furthermore, given a parser, it should be possible to automatically 
produce a summary of all the options that it supports, to be pre¬ 
sented to the user of the tool as documentation. 

We can define a data structure representing a parser for an individ¬ 
ual option, with a specified type, as a functor: 
data Option a = Option 
{ optName :: String 
, optDefault :: Maybe a 
, optReader :: String — > Maybe a} 
deriving Functor 

We now want to create a DSL based on the Option functor, which 
would allow us to combine options for different types into a single 
value representing the full parser. As stated in the introduction, a 
common way to create a DSL from a functor is to use free monads. 
However, taking the free monad over the Option functor would not 
be very useful here. First of all, sequencing of options should be 
independent : later options should not depend on the value parsed 
by previous ones. Secondly, monads cannot be inspected without 
running them, so there is no way to obtain a summary of all options 
of a parser automatically. 

What we really need is a way to construct a parser DSL in such 
a way that the values returned by the individual options can be 
combined using an Applicative interface. And that’s exactly 
what FreeA will provide. 

Thus, if we use FreeA Option a as our embedded DSL, we can 
interpret it as the type of a parser with an unspecified number of 
options, of possibly different types. When run, those options would 
be matched against the input command line, in an arbitrary order, 
and the resulting values will be eventually combined to obtain a 
final result of type a. 

In our specific example, an expression to specify the command line 
option parser for create_user would look like this: 
userP :: FreeA Option User 
userP = User 

<$> one (Option "username" Nothing Just) 

<*> one (Option "fullname" (Just "") Just) 

<*> one (Option "id" Nothing readlnt) 
readlnt :: String —> Maybe Int 


where we need a “generic smart constructor”: 

one :: Option a —> FreeA Option a 
which lifts an option to a parser. 

1.3 Example: limited IO 

One of the applications of free monads, exemplified in fl3l . is the 
definition of special-purpose monads, allowing to express compu¬ 
tations which make use of a limited and well-defined subset of IO 
operations. 

Given the following functor: 
data FileSystem a = 

Read FilePath (String — >• a) 

| Write FilePath String a 
deriving Functor 

the free monad on FileSystem, once “smart constructors” are 
defined for the two basic operations of reading and writing, allows 
to express any operation on files with the same convenience as the 
10 monad. 

For example, one can implement a copy operation as follows: 
copy :: FilePath —¥ FilePath —> Free FileSystem () 
copy src dst = read src >= write dst 
For some applications, we might need to have more control over 
the operations that are going to be executed when we eventu¬ 
ally run the embedded program contained in a value of type 
Free FileSystem a. 

For example, it could be useful to print a summary of the files that 
are going to be overwritten, and how much data in total is going to 
be written to disk. 

However, there is no way to do that using the free monad approach. 
For example, there is no function: 

count :: Free FileSystem a —y Int 
which returns the number of read/write operations performed by a 
monadic value. 

To see why, consider the following example: 
ex :: Free FileSystem () 
ex = do 

s •<— read "/etc/motd" 
when (null s) $ 

write "/tmp/out" "" 

Now, ex performs 1 operation if and only if /etc/motd is empty, 
which, of course, cannot be determined by a pure function like 

The FreeA construction, presented in this paper, represents a gen¬ 
eral solution for the problem of constructing embedded languages 
that allow the definition of functions performing static analysis on 
embedded programs, of which count :: FreeA FileSystem a —¥ 
Int is a very simple example. 

1.4 Example: applicative parsers 

The idea that monads are “too flexible” has also been explored, 
again in the context of parsing, by Swierstra and Duponcheel ( 02 )), 
who showed how to improve both performance and error-reporting 
capabilities of an embedded language for grammars by giving up 
some of the expressivity of monads. 

The basic principle is that, by weakening the monadic interface 
to that of an applicative functor (or, more precisely, an alternative 
functor), it becomes possible to perform enough static analysis to 
compute first sets for productions. 

The approach followed in fl2) is ad-hoc: an applicative functor is 
defined, which keeps track of first sets, and whether a parser accepts 
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the empty string. This is combined with a traditional monadic 
parser, regarded as an applicative functor, using a generalized semi- 
direct product, as described in flo). 

The question, then, is whether it is possible to express this con¬ 
struction in a general form, in such a way that, given a functor 
representing a notion of “parser” for an individual symbol in the 
input stream, applying the construction one would automatically 
get an Applicative functor, allowing such elementary parsers to be 
sequenced. 

Free applicative functors can be used to that end. We start with a 
functor f, such that f a describes an elementary parser for individ¬ 
ual elements of the input, returning values of type a. FreeA f a is 
then a parser which can be used on the full input, and combines all 
the outputs of the individual parsers out of which it is built, yielding 
a result of type a. 

Unfortunately, applying this technique directly results in a strictly 
less expressive solution. In fact, since FreeA f is the simplest 
applicative over f, it is necessarily just and applicative, i.e. it cannot 
also have an Alternative instance, which in this case is essential. 
We discuss the issue of Alternative in more detail in sectionfTOl 

2. Definition 

To obtain a suitable definition for the free applicative functor gen¬ 
erated by a functor f, we first pause to reflect on how one could 
naturally arrive at the definition of the Applicative class via an 
obvious generalisation of the notion of functor. 

Given a functor f, the fmap method gives us a way to lift unary 
pure functions a —t b to effectful functions f a 4 £ b, but what 
about functions of arbitrary arity? 

For example, given a value of type a, we can regard it as a nullary 
pure function, which we might want to lift to a value of type f a. 
Similarly, given a binary function h :: a -4 b -4 c, it is quite 
reasonable to ask for a lifting of h to something of type f a —t 
fb4fc, 

The Functor instance alone cannot provide either of such liftings, 
nor any of the higher-arity liftings which we could define. 

It is therefore natural to define a type class for generalised functors, 
able to lift functions of arbitrary arity: 

class Functor f =4 MultiFunctor f where 

fmapj :: (a4b) 4f a4f b 
fmapj = fmap 

fmap 2 :: (a4b4c) 4f a4f b4f c 

It is easy to see that a higher-arity fmap n can now be defined in 
terms of fmap 2 . For example, for n = 3: 

fmap 3 :: MultiFunctor f 

=>■ (a —4 b -4 c -4 d) 

4fa4fb4fc4fd 
fmap 3 h x y z = fmap 2 ( $ ) (fmap 2 h x y) z 

However, before trying to think of what the laws for such a type 
class ought to be, we can observe that MultiFunctor is actually 
none other than Applicative in disguise. 

In fact, fmap 0 has exactly the same type as pure, and we can easily 
convert fmap 2 to ( <*> ) and vice versa: 

g <*> x = fmap 2 ( $ ) g x 
fmap 2 h x y = fmap h x <*> y 

The difference between ( <*> ) and fmap 2 is that ( <*> ) expects 
the first two arguments of fmap 2 , of types a —4 b —4 c and 
f a respectively, to be combined in a single argument of type 
f (b -4 c). 


This can always be done with a single use of fmap, so, if we assume 
that f is a functor, ( <*> ) and fmap 2 are effectively equivalent. 
Nevertheless, this roundabout way of arriving to the definition of 
Applicative shows that an applicative functor is just a functor 
that knows how to lift functions of arbitrary arities. An overloaded 
notation to express the application of f map i for all i is defined in 
t9l . where it is referred to as idiom brackets. 

Given a pure function of arbitrary arity and effectful arguments: 

h : bi -4 b 2 -4-4 b n -4 a 

xi : f bi 
x 2 : f b 2 

x„:f b„ 

the idiom bracket notation is defined as: 

I h XI X2 ■ • • x n ] = pure h <*> xi <*> x 2 <*>••• <*> x n 

We can build such an expression formally by using a PureL con¬ 
structor corresponding to pure and a left-associative infix ( : *: ) 
constructor corresponding to ( <*> ): 

PureL h : *: Xi : *: x 2 : * : ■ ■ ■ : * : x n 
The corresponding inductive definition is: 
data FreeAL f a 
= PureL a 

| Vb.FreeAL f (b4a):*:fb 

infixl 4 

The MultiFunctor typeclass, the idiom brackets and the FreeAL 
definition correspond to the left parenthesised canonical fom£] of 
expressions built with pure and ( <*> ). Just as lists built with 
concatenation have two canonical forms (cons-list and snoc-list) we 
can also define a right-parenthesised canonical form for applicative 
functors — a pure value over which a sequence of effectful func¬ 
tions are applied: 

x: bi 

hi :f (bi4 b 2 ) 
h 2 : f (b 2 —4 b 3 ) 

h„ : f (b n -4 a) 

bn <*> (• ■ • <*> (h2 <*> (hi <*> pure x)) • • •) 
Replacing pure with a constructor Pure and ( <*> ) by a right- 
associative infix ( : $: ) constructor gives the following expression: 

h n h 2 : $: hi : $: Pure x 

The corresponding inductive type: 
data FreeA f a 
= Pure a 

| Vb.f (b -4 a) :$: FreeA f b 

infixr 4 : $ : 

FreeAL and FreeA are isomorphic (see section |5J, we pick the 
right-parenthesised version as our official definition since it is sim¬ 
pler to define the Functor and Applicative instances: 

instance Functor f =4 Functor (FreeA f) where 
fmap g (Pure x) = Pure (g x) 
fmap g (h : $ : x) = fmap (g o ) h : $ : x 

1 Sometimes called simplified form because it is not necessarily unique. 


2013/4/3 


The functor laws can be verified by structural induction, simply 
applying the definitions and using the functor laws for f. 

instance Functor f => Applicative (FreeA f) where 
pure = Pure 

Pure g <*> y = fmap g y 

(h : $ : x) <*> y = fmap uncurry h : $ : 

(( , ) <$> x <*> y) 

In the last clause of the Applicative instance, h has type f (x — } 
y —»• z), and we need to return a value of type FreeA f z. 
Since ( : $: ) only allows us to express applications of 1-argument 
“functions”, we uncurry h to get a value of type f ((x , y) —> z), 
then we use ( <*> ) recursively (see section[8]for a justification of 
this recursive call) to pair x and y into a value of type FreeA f (x , 
y), and finally use the ( : $: ) constructor to build the result. Note 
the analogy between the definition of ( <*> ) and ( Tf ) for lists. 

3. Applications 

3.1 Example: option parsers (continued) 

By using our definition of free applicative, we can compose the 
command line option parser exactly as shown in section |1.2| in 
the definition of userP. The smart constructor one which lifts an 
option (a functor representing a basic operation of our embedded 
language) to a term in our language can now be implemented as 
follows: 

one :: Option a —> FreeA Option a 
one opt = fmap const opt :$: Pure () 

In section[7]we generalize one to any functor and by using generic 
functions specified as part of the adjunction we define functions 
which make use of the fact that it is possible to statically analyse a 
parser definition: functions are given for listing all possible options 
and for parsing a list of command line arguments given in arbitrary 

3.2 Example: limited IO (continued) 

In section[T3]we showed an embedded DSL for file system opera¬ 
tions based on free monads does not support certain kinds of static 
analysis. 

However, we can now remedy this by using a free applicative, over 
the same functor FileSystem. In fact, the count function is now 
definable for FreeA FileSystem a. Moreover, this is not limited 
to this particular example: it is possible to define count for the free 
applicative over any functor, 
count :: FreeA f a-> Int 
count (Pure _) = 0 
count ( : $: u) = 1 + count u 

Of course, the extra power comes at a cost. Namely, the expressivity 
of the corresponding embedded language is severely reduced. 
Using FreeA FileSystem, the files on which read and write op¬ 
erations are performed must be known in advance, as well as the 
content that is going to be written. 

In particular, what one writes to a file cannot depend on what has 
been previously read, so operations like copy cannot be imple¬ 
mented. 

3.3 Summary of examples 

Applicative functors are useful for describing certain kinds of ef- 
fectful computations. The free applicative construct over a given 
functor specifying the “basic operations” of an embedded language 
gives rise to terms of the embedded DSL built by applicative oper¬ 
ators. These terms are only capable of representing a certain kind 
of effectful computation which can be described best with the help 


of the left-parenthesised canonical form: a pure function applied 
to effectful arguments. The calculation of the arguments may in¬ 
volve effects but in the end the arguments are composed by a pure 
function, which means that the effects performed are fixed when 
specifying the applicative expression. 

In the case of the option parser example userP, the pure function 
is given by the User constructor and the “basic operation” Option 
is defining an option. The effects performed depend on how an 
evaluator is defined over an expression of type FreeA Option a 
and the order of effects can depend on the implementation of the 
evaluator. 

For example, if one defines an embedded language for querying a 
database, and constructs applicative expressions using FreeA, one 
might analyze the applicative expression and collect information 
on the individual database queries by defining functions similar 
to the count function in the limited IO example. Then, different, 
possibly expensive duplicate queries can be merged and performed 
at once instead of executing the effectful computations one by one. 
By restricting the expressivity of our language we gain freedom in 
defining how the evaluator works. 

One might define parts of an expression in an embedded DSL using 
the usual free monad construction, other parts using FreeA and 
compose them by lifting the free applicative expression to the free 
monad using the following function: 

liftA2M :: Functor f => FreeA f a —» Free f a 
liftA2M (Pure x) = Return x 
liftA2M (h :$: x) = Free 

(fmap (Af —» fmap f (liftA2M x)) h) 

In the parts of the expression defined using the free monad con¬ 
struction, the order of effects is fixed and the effects performed 
can depend on the result of previous effectful computations, while 
the free applicative parts have a fixed structure with effects not de¬ 
pending on each other. The monadic parts of the computation can 
depend on the result of static analysis carried out over the applica¬ 
tive part: 

test :: FreeA FileSystem Int —> Free FileSystem () 
test op = do 

let n = count op — result of static analysis 

n' <— lif tA2M op — result of applicative computation 

when (max n + n') $ write "/tmp/test" "blah" 

The possibility of using the results of static analysis instead of the 
need of specifying them by hand (in our example, this would ac¬ 
count to counting certain function calls in an expression by looking 
at the code) can make the program less redundant. 

4. Parametricity 

In order to prove anything about our free applicative construction, 
we need to make an important observation about its definition. 

The ( : $: ) constructor is defined using an existential type b, and 
it is clear intuitively that there is no way, given a value of the form 
g : $: x, to make use of the type b hidden in it. 

More specifically, any function on FreeA f a must be defined 
polymorphically over all possible types b which could be used for 
the existentially quantified variable in the definition of ( : $: ). 

To make this intuition precise, we appeal to the notion of relational 
parametricity ( fill . fl4l ). which, specialised to the ( :$: ) con¬ 
structor, implies that: 

( : $: ) :: Vb.f (b —> a) —k (FreeA f b —> FreeA f a) 
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is a natural transformation of contravariant functors. The two 
contravariant functors here could be defined, in Haskell, using a 

newtype: 

newtype FI f a x = FI (f (x —> a) ) 
newtype F2 f a x = F2 (FreeA f x-> FreeA f a) 
instance Functor f 3- Contravariant (FI f a) where 
contramap h (FI g) = FI $ fmap (oh) g 
instance Functor f => Contravariant (F2 f a) where 
contramap h (F2 g) = F2 $ g o fmap h 
The action of FI and F2 on morphisms is defined in the obvious 
way. Note that here we make use of the fact that FreeA f is a 
functor. 

Naturality of ( : $: ) means that, given types x and y, and a function 
h : x —¥ y, the following holds: 

Vg :: f (y —>• a),u :: FreeA f x. 
fmap (oh)g:$:u = g:$: fmap h u (1) 

where we have unfolded the definitions of contramap for FI and 
F2, and removed the newtypes. 

5. Isomorphism of the two definitions 

In this section we show that the two definitions of free applicatives 
given in section |2] are isomorphic. 

First of all, if f is a functor, FreeAL f is also a functor: 
instance Functor f 3- Functor (FreeAL f) where 
fmap g (PureL x) = PureL (g x) 
fmap g (h : * : x) = (fmap (g o ) h) : * : x 
Again, the functor laws can be verified by a simple structural 
induction. 

For the ( : *: ) constructor, a free theorem can be derived in a 
completely analogous way to deriving equation [l] This equation 
states that ( : *: ) is a natural transformation: 

Vh :: x —> y, g :: FreeAL f (y —> a),u :: f x. 
fmap (oh)g:*:u3g:*: fmap h u (2) 

We define functions to convert between the two definitions: 
r21:: Functor f 3- FreeA f a FreeAL f a 
r21 (Pure x) = PureL x 

r21 (h : $ : x) = fmap (flip ( $ ) ) (r21 x) : *: h 
12r :: Functor f 3> FreeAL f a FreeA f a 
12r (PureL x) = Pure x 

12r (h : *: x) = fmap (flip ( $ ) ) x : $ : 12r h 
We will also need the fact that 12r is a natural transformation: 

Vh :: x —> y, u :: FreeAL f x. 

12r (fmap hu) s fmap h (12r u) (3) 

Proposition 1. r21 is an isomorphism, the inverse of which is 12r. 

Proof. First we prove that Vu :: FreeA f a. 12r (r21 u) = u. We 
compute using equational reasoning with induction on u: 

12r (r21 (Pure x)) 

= { definition of r21} 

12r (PureL x) 

3 { definition of 12r ) 

12r (r21 (h :$: x)) 

3 { definition of r21) 

12r (fmap (flip ( $ )) (r21 x) h) 


3 { definition of 12r ) 
fmap (flip ( $ ) ) h : $ : 

12r (fmap (flip ( $ )) (r21 x)) 

3 ( equation]!]) 
fmap (flip ( $ )) h :$: 
fmap (flip ( $ )) (12r (r21 x) ) 

3 (inductive hypothesis ) 
fmap (flip ( $ ) ) h : $: fmap (flip ( $ ) ) x 
3 ( equation]!]) 

fmap ( o (flip ( $ ) ) ) (fmap (flip ( $ ) ) h) : $ : x 
31 f is a functor ) 

fmap ( ( o (flip ($))) oflip ($)) h : $: x 
3 ( definition of flip and ( $ ) ) 
fmap id h : $ : x 
3 ( f is a functor ) 
h :$: x 

Next, we prove that Vu :: FreeAL f a.r21 (12r u) 3 u. Again, 
we compute using equational reasoning with induction on u: 

r21 (12r (PureL x)) 

3 { definition of 12r ) 
r21 (Pure x) 

3 ( definition of r21) 

PureL x 

r21 (12r (h x)) 

3 | definition of 12r ) 
r21 (fmap (flip ( $ ) ) x : $: 12r h) 

3 ( definition of r21) 

fmap (flip ( $ )) (r21 (12r h) ) : *: fmap (flip ( $ )) x 
3 (inductive hypothesis ) 
fmap (flip ( $ )) h : *: fmap (flip ( $ )) x 
3 ( equation]!]) 

fmap ( o (flip ( $ ) ) ) (fmap (flip ( $ ) ) h) : * : x 
3 ( FreeAL f is a functor ) 
fmap ( ( o (flip ( $ ) ) ) o flip ( $ ) ) h : * : x 
3 { definition of flip and ( $ ) ) 
fmap id h : * : x 
3 ( FreeAL f is a functor ) 


□ 


In the next sections, we will prove that FreeA is a free applicative 
functor. Because of the isomorphism of the two definitions, these 
results will carry over to FreeAL. 

6. Applicative laws 

Following QD, the laws for an Applicative instance are: 

pure id <*> u 3 u (4) 

pure ( o ) <*> u <*> v <*> x 3 u <*> (v <*> x) (5) 

pure f <*> pure x 3 pure (f x) (6) 

u <*> pure x 3 pure ( $ x) <*> u (7) 

We introduce a few abbreviations to help make the notation lighter: 

uc = uncurry 

pair x y — ( s ) <$> x <*> y 
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Lemma 1. For all 


u :: y 3 z 

v :: FreeA f (x 3 y,) 
x :: FreeA f x 

the following equation holds: 

f map u (sr <*>x) = f map (u o ) v <*> x 
Proof. We compute: 

fmap u (Pure v <*> x) 

= ( definition of ( <*> ) } 
fmap u (fmap v x) 

= { FreeA f is a functor } 
fmap (u o v) x 
= ( definition of ( <*> ) } 

Pure (u o v) <*> x 
3 { definition of fmap ) 
fmap (u o ) (Pure v) <*> x 

fmap u ((g :$: y) <*> x) 

3 ( definition of ( <*> ) } 
fmap u (fmap uc g : $ : pair y x) 

3 f definition of fmap ) 
fmap (u o ) (fmap uc g) : $ : pair y x 
S f is a functor) 

fmap (Ag -tuoucg) g:$: pair y x 
3 ( f is a functor} 

fmap uc (fmap ( (u o ) o ) g) : $ : pair y x 
3 { definition of ( <*> ) ) 

(fmap ( (u o ) o ) g : $: y) <*> x 
3 ( definition of fmap } 
fmap (u o ) (g : $: y) <*> x 

□ 

Lemma 2. Prop e rty [5] ho Ids fo r FreeA f, i.e. for all 
u :: FreeA f (y 3 z) 
v :: FreeA f (x 3 y.) 
x :: FreeA f x, 

pure ( o ; <*> u <*> v <*> x 3 u <*> (v <*> x) 

Proof Suppose first that u = Pure u 0 for some u 0 :: y 3- z: 

Pure ( o ) <*> Pure u 0 <*> v <*> x 
3 { definition of ( <*> ) ) 

Pure (u 0 o ) <*> v <*> x 
3 ( definition of ( <*> ) } 
fmap (uo o ) v <*> x 
3 { lemma[T|) 
fmap u 0 (v <*> x) 

3 ( definition of ( <*> ) } 

Pure u 0 <*> (v <*> x) 

To tackle the case where u = g : $: w, for 
g :: f (w 3- y 3- z) 
w :: FreeA f w, 

we need to define a helper function 
t :: ( (w , x 3 y) , x) 3 (w , y) 
t ((w , v) , x) — (w , v x) 
and compute: 


pure ( o ) <*> (g : $ : w) <*> v <*> x 
3 ( definition of pure and ( <*> ) } 

(fmap ((o)o)g:$:w) <*> v <*> x 
3 { definition of composition ) 

(fmap (Ag wv3gwov)g:$:w) <*> v <*> x 
3 { definition of ( <*> ) ) 

(fmap uc (fmap (Ag w v 3 g w o v) g) pair w v) 

3 ( f is a functor and definition of uc ) 

(fmap (Ag (w , v) 3 g w o v) g : $ : pair w v) <*> x 
3 { definition of ( <*> ) ) 
fmap uc (fmap (Ag (w , v) 3 g w o v) g) : $: 
pair (pair w v) x 
3 { f is a functor and definition of uc ) 
fmap (Ag ( (w , v) , x) 3 g w (v x) ) g : $: 
pair (pair w v) x 
3 ( definition of uc and t } 
fmap (Ag 3 uc g o t) g : $: pair (pair w v) x 
31 f is a functor ) 

fmap (ot) (fmap uc g) : $ : pair (pair w v) x 
3 ( equation IT] ) 

fmap uc g : $: fmap t (pair (pair w v) x) 

3 ( lemma[I](3 times) and FreeA f is a functor (3 times)) 
fmap uc g : $ : (pure ( o ) <*> fmap ( , ) w <*> v <*> x) 
3 {induction hypothesis for fmap ( , ) w ) 
fmap uc g : $ : (fmap ( , ) w <*> (v <*> x) ) 

3 ( definition of ( <*> ) ) 

(g :$: w) <*> (v<*>x) 

□ 

Lemma 3. Property^holds for FreeA f, i.e. for all 
u :: FreeA f (x 3 y^ 


u <*> pure x = pure ( $ x) <*> u 

Proof. If u is of the form Pure u 0 , then the conclusion follows 
immediately. 

Let’s assume, therefore, thatu = g :$: w, for some w::w, g::f (w 3 
x 3 y), and that the lemma is true for structurally smaller values 
of u: 

(g :$: w) <*> pure x 
3 ( definition of ( <*> ) ) 
fmap uc g : $ : pair w (pure x) 

3 ( definition of pair ) 
fmap uc g : $ : (fmap ( , ) w <*> pure x) 

3 {induction hypothesis for fmap ( , ) w ) 
fmap uc g : $: (pure ( $ x) <*> fmap ( , ) w) 

3 ( FreeA f is a functor ) 
fmap uc g : $: fmap (Aw 3 (w , x)) w) 

3 { equation[l]) 

fmap (Ag w 3 g (w , x) ) (fmap uc g) : $ : w 
3 ( f is a functor ) 
fmap (Ag w 3 g w x) g : $ : w 
3 { definition of fmap for FreeA f ) 
fmap ( $ x) (g : $ : w) 

3 { definition of ( <*> ) ) 
pure ( $ x) <*> (g :$: w) 

□ 

Proposition 2. FreeA f is an applicative functor. 


2013/4/3 




Proof. Properties [4] and [6] are straightforward to verify using the 
fact that FreeA f is a functor, while properties0and[7]follow from 
le [2] IQ] e |e t ely. □ 

7. FreeA as a Left adjoint 

We now want to show that FreeA f is really the free applicative 
functor on f. For that, we need to define a category of applicative 
functors A, and show that FreeA is a functor 
FreeA : T —> .4, 

where T is the category of endofunctors of Hask, and that FreeA 
is left adjoint to the forgetful functor A —> T. 

Definition 1. Let f and g be two applicative functors. An applica¬ 
tive natural transformation between f and g is a polymorphic func- 

t :: Va.f a^ga 
satisfying the following laws: 

t (pure x.) 3 pure x (8) 

t (h<*>x; = th<*>tx. (9) 

We define the type of all applicative natural transformations be¬ 
tween f and g, we write, in Haskell, 
type AppNat fg = Va.f a-tga 
where the laws are implied. 

Similarly, for any pair of functors f and g, we define 
type Nat f g = Va.f a^ga 
for the type of natural transformations between f and g. 

Note that, by parametricity, polymorphic functions are automati¬ 
cally natural transformations in the categorical sense, i.e, for all 
t :: Nat f g 
h::a3b 


t (fmap hx)s fmap h (t x). 

It is clear that applicative functors, together with applicative natural 
transformations, form a category, which we denote by A, and 
similarly, functors and natural transformations form a category T. 

Proposition 3. FreeA defines a functor IF —¥ A. 

Proof. We already showed that FreeA sends objects (functors in 
our case) to applicative functors. 

We need to define the action of FreeA on morphisms (which are 
natural transformations in our case): 
liftT :: (Functor f , Functor g) 

3- Nat f g 

—» AppNat (FreeA f) (FreeA g) 
liftT _ (Pure x) = Pure x 
liftT k (h : $ : x) = k h : $ : liftT k x 
First we verify that liftTkisan applicative natural transformation 
i.e. it satisfies laws [8] and [9] We use equational reasoning for 
proving law [8] 

liftT k (pure x) 

= ( definition of pure ) 
liftT k (Pure x) 

= ( definition of liftT ) 

Pure x 

= ( definition of pure ) 


For law [9] we use induction on the size of the first argument of 

( <*> ) as explained in section[8] The base cases: 

liftT k (Pure h <*> Pure x) 

3 { definition of ( <*> ) ) 
liftT k (fmap h (Pure x)) 

3 ( definition of fmap ) 
liftT k (Pure (h x)) 

3 { definition of liftT ) 

Pure (h x) 

3 ( definition of fmap ) 
fmap h (Pure x) 

= ( definition of ( <*> ) ) 

Pure h <*> Pure x 
3 ( definition of liftT ) 
liftT k (Pure h) <*> liftT k (Pure x) 

liftT k (Pure h <*> (i : $ : x) ) 

3 ( definition of ( <*> ) ) 
liftTk (fmaph (i :$: x)) 

3 ( definition of fmap ) 
liftT k (fmap (ho) i :$:x) 

3 ( definition of liftT ) 
k (fmap (ho) i) : $: liftT k x 
31 k is natural} 

fmap (ho) (k i) : $: liftT k x 
3 ( definition of fmap ) 
fmap h (k i : $: liftT k x) 

3 ( definition of ( <*> ) ) 

Pure h <*> (k i : $: liftT k x) 

3 ( definition of liftT ) 
liftT k (Pure h) <*> liftT k (i :$: x) 

The inductive case: 

liftT k ((h x) <*> y) 

3 ( definition of ( <*> ) ) 

liftT k (fmap uncurry h : $ : (fmap ( , ) x <*> y) 

3 ( definition of liftT ) 

k (fmap uncurry h) :$: liftT k (fmap ( , ) x <*> y) 

3 (inductive hypothesis ) 
k (fmap uncurry h) : $: 

(liftT k (fmap ( , ) x) <*> liftT k y) 

3 (liftT k is natural) 
k (fmap uncurry h) : $: 

(fmap ( , ) (liftT k x) <*> liftT k y) 

3 { k is natural) 
fmap uncurry (k h) : $ : 

(fmap ( , ) (liftT k x) <*> liftT k y) 

3 { definition of ( <*> ) ) 

(k h : $ : liftT k x) <*> liftT k y 
3 { definition of liftT ) 
liftT k (h : $: x) <*> liftT k y 

Now we need to verify that liftT satisfies the functor laws 
liftT id 3 id 

liftT (t o u) 3 liftT t o liftT u. 

The proof is a straightforward structural induction. ^ 

We are going to need the following natural transformation: 

one :: Functor f 3- Nat f (FreeA f) 
one x = fmap const x : $ : Pure () 
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which embeds any functor f into FreeAf (we used a specialization 
of this function for Option in section [L2] >. 

Lemma 4. 

Proof. Given 

h :: a —> (() , a) 
h x = (() , x) 
it is easy to verify that: 

( o h) o uncurry o const = id, (10) 


one g <*> x 
3 ( definition of one ) 

(fmap const g Pure ()) <*> x 
3 ( definition of ( <*> ) and functor law for f } 
fmap (uncurry o const) g : $ : fmap h x 
= ( equation [I] and functor law for f ) 
fmap ((oh) o uncurry o const) g : $ : x 
= (equation[To|) 
g x 

la 

Proposition 4. The Freek functor is left adjoint to the forgetful 
functor A —>• T. Graphically: 

Lfomjr(FreeA f, g) = iJorrM,(f,g) 

Proof. Given a functor f and an applicative functor g, we define a 
natural bijection between Nat f g and AppNat (FreeA f) g as 

raise :: (Functor f , Applicative g) 

=> Nat f g 

—y AppNat (FreeA f) g 
raise _ (Pure x) = pure x 
raise k (g :$: x) = kg <*> raise k x 
lower :: (Functor f , Applicative g) 

=> AppNat (FreeA f) g 
-¥ Nat f g 
lower k=ko one 

A routine verification shows that raise and lower are natural in 
f and g. The proof that raise k satisfies the applicative natural 
transformation laws [8] and [9] is a straightforward induction having 
the same structure as the proof that liftT k satisfies these laws 
(proposition[3|. To show that f and g are inverses of each other, we 
reason by induction and calculate in one direction: 
raise (lower t) (Pure x) 

3 { definition of raise } 

3 (t is an applicative natural transformation ) 
t (pure x) 

3 ( definition of pure ) 
t (Pure x) 

raise (lower t) (g x) 

3 ( definition of raise ) 
lower t g <*> raise (lower t) x 
3 {induction hypothesis ) 
lower t g <*> t x 


3 { definition of lower ) 
t (one g) <*> t x 

3 {t is an applicative natural transformation ) 
t (one g <*> x) 

3 ( lemmaRl) 
t (g : $: x) 

The other direction: 

lower (raise t) x 
3 { definition of lower ) 
raise t (one x) 

3 { definition of one ) 
raise t (fmap const x :$: Pure ()) 

3 { definition of raise ) 
t (fmap const x) <*> pure () 

•Hi! t is natural) 

fmap const (t x) <*> pure () 

3 { fmap h 3 ((pure h) <*> ) in an applicative functor ) 
pure const <*> t x <*> pure () 

3 {t is natural) 

pure ( $ 0 ) <*> (pure const <*> t x) 

3 ( applicative law[5]) 

pure ( o ) <*> pure ( $ 0 ) <*> pure const <*> t x 
3 { applicative law[6]applied twice ) 

3 (applicative law[4]} 

ii 

7.1 Example: option parsers (continued) 

With the help of the adjunction defined above by raise and 
lower we are able to define some useful functions. In the case of 
command-line option parsers, for example, it can be used for com¬ 
puting the global default value of a parser: 

parserDefault :: FreeA Option a —> Maybe a 
parserDefault = raise optDefault 
or for extracting the list of all the options in a parser: 
allOptions :: FreeA Option a —> [String] 
allOptions = getConst o raise f 

f opt = Const [optName opt] 

allOptions works by first defining a function that takes an option 
and returns a one-element list with the name of the option, and then 
lifting it to the Const applicative functor. 

Using parserDefault, we can now write a function that runs an 
applicative option parser over a list of command-line arguments, 
accepting them in any order: 

matchOpt :: String — )• String 
3- FreeA Option a 
—¥ Maybe (FreeA Option a) 

matchOpt_ (Pure _) = Nothing 

matchOpt opt value (g :$: x) 

| opt 3 : optName g 

= fmap ( <$> x) (optReader g value) 

| otherwise 

= fmap (g :$: ) (matchOpt opt value x) 
runParser :: FreeA Option a 
3- [String] 

runParser p (opt : value : args) = 
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case matchOpt opt value p of 
Nothing —» Nothing 
Just p' —¥ runParser p' args 
runParser p [] = parserDefault p 
runParser_= Nothing 

The mat chOpt function looks for options in the parser which match 
the given command-line argument, and, if successful, returns a 
modified parser where the option has been replaced by a pure value. 
Finally, runParser calls matchOpt with successive pairs of argu¬ 
ments, until no arguments remain, at which point it uses the default 
values of the remaining options to construct a result. 

8. Totality 

All the proofs in this paper apply to a total fragment of Haskell, and 
completely ignore the presence of bottom. 

To justify the validity of our results, then, we need to ensure that all 
definitions are actually possible in a total language. 

In fact, all our ADT definitions can be regarded as inductive fix- 
points of strictly positive functors, and most of the function defini¬ 
tions use primitive recursion, so they are obviously terminating for 
all inputs. Furthermore, most proofs are carried out by structural 
induction. 

One exception is the definition of ( <*> ): 

(h : $: x) <*> y = fmap uncurry h : $ : ( ( , ) <$> x <*> y) 

which contains a recursive call where the first argument, namely 
( , ) <$>x, is not structurally smaller than the original one (h : $: x). 
To prove that this function is nevertheless total, we introduce a 
notion of size for values of type FreeA f a: 
size :: FreeA f a -> N 
size (Pure m 0 
size (_ : $: x) = 1 + size x 

To conclude that the definition of ( <*> ) is indeed terminating, 
we just need to show that the size of argument for the recursive 
call is smaller than the size of the original argument, which is an 
immediate consequence of the following lemma. 

Lemma 5. For any function f :: a —¥ b and u :: FreeA f a, 
size (fmap f u}e size u 
Proof By induction: 

size (fmap f (Pure x) ) 

= { definition of fmap ) 
size (Pure (f x)) 

= ( definition of size ) 

0 

= { definition of size } 
size (Pure x) 

size (fmap f (g : $ : x) ) 

= { definition of fmap } 
size (fmap (fo)g:$:x) 

= { definition of size } 

= { definition of size ) 
size (g:$:x) 

D 

In most of our proofs using induction we carry out induction on the 
size of the first argument of ( <*> ) where size is defined by the 
above size function. 


9. Related work 

The idea of free applicative functors is not entirely new. There have 
been a number of different definitions of free applicative functor 
over a given Haskell functor, but none of them includes a proof of 
the applicative laws. 

The first author of this paper published a specific instance of ap- 
plicative functors similar to our example shown in section 1 1 ,2| 
(Ell. The example was developed further in the Haskell package 
optparse-applicative ( 31 - 

Tom Ellis proposes a definition very similar to ours (|6|), but uses 
a separate inductive type for the case corresponding to our ( : $: ) 
constructor. He then observes that law [6] probably holds because 
of the existential quantification, but doesn’t provide a proof. We 
solve this problem by deriving the necessary equation[T|as a “free 
theorem”. 

Gergo Erdi gives another similar definition ( 0 ), but his version 
presents some redundancies, and thus fails to obey the applicative 
laws. For example. Pure id <*> x can easily be distinguished from 
x using the count function defined above. 

The free package on hackage ((TJ) contains a definition essentially 
identical to our FreeAL, differing only in the order of arguments. 
Another approach, which differs significantly from the one pre¬ 
sented in the paper, underlies the definition contained in the 
f ree-f unctors package on hackage ( 0 ), and uses a Church-like 
encoding (and the ConstraintKinds GHC extension) to general¬ 
ize the construction of a free Applicative to any superclass of 
Functor. 

The idea is to use the fact that, if a functor T has a left adjoint F, 
then the monad FoT is the codensity monad of T (i.e. the right Kan 
extension of T along itself). By taking T to be the forgetful functor 
A —»• T, one can obtain a formula for F using the expression of a 
right Kan extension as an end. 

One problem with this approach is that the applicative laws, which 
make up the definition of the category A, are left implicit in the 
universal quantification used to represent the end. 

In fact, specializing the code in Data.Functor.HFree to the 
Applicative constraint, we get: 

data FreeA' f a = FreeA' { 

runFreeA :: Vg. Applicative g 

*=> CVx.f x-tgx)4ga} 
instance Functor f =>• Functor (FreeA' f) where 
fmap h (FreeA' t) = FreeA' (fmap hot) 
instance Functor f => Applicative (FreeA' f) where 
pure x = FreeA' (\_ —> pure x) 

FreeA' tl <*> FreeA' t2 = 

FreeA' (Au -^tlu <*> t2 u) 

Now, for law[4]to hold, for example, we need to prove that the term 
Au —y pure id <*> t u is equal to t. This is strictly speaking 
false, as those terms can be distinguished by taking any functor 
with an Applicative instance that doesn’t satisfy law[4] and as t 
a constant function returning a counter-example for it. 

Intuitively, however, the laws should hold provided we never make 
use of invalid Applicative instances. To make this intuition pre¬ 
cise, one would probably need to extend the language with quan¬ 
tification over equations, and prove a parametricity result for this 
extension. 

Another problem of the Church encoding is that it is harder to 
use. In fact, the destructor runFreeA is essentially equivalent to 
our raise function, which can only be used to define applicative 
natural transformation. A function like matchOpt in section |7J) 
which is not applicative, could not be defined over FreeA'. 
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10. Discussion and further work 

We have presented a practical definition of free applicative functor 
over any Haskell functor, proved its properties, and showed some 
of its applications. As the examples in this paper show, free ap¬ 
plicative functors solve certain problems very effectively, but their 
applicability is somewhat limited. 

For example, applicative parsers usually need an Alternative in¬ 
stance as well, and the free applicative construction doesn’t provide 
that. One possible direction for future work is trying to address this 
issue by modifying the construction to yield a free Alternative 
functor, instead. 

Unfortunately, there is no satisfactory set of laws for alternative 
functors: if we simply define an alternative functor as a monoid 
object in A, then many commonly used instances become invalid, 
like the one for Maybe. 

Another direction is formalizing the proofs in this paper in a proof 
assistant, by embedding the total subset of Haskell under consider¬ 
ation into a type theory with dependent types. 

Our attempts to replicate the proofs in Agda have failed, so far, 
because of subtle issues in the interplay between parametricity and 
the encoding of existentials with dependent sums. 

In particular, equation[l]is inconsistent with a representation of the 
existential as a S type in the definition of FreeA. For example, 
terms like const () : $: Pure 3 and id : $: Pure () are equal by 
equation[l] but can obviously be distinguished using large elimina- 

The problem seems to be related to the difference in predicativity 
between System F and Martin-Lof type theory. Using the approach 
in (7) to add parametricity to the theory, one obtains a statement 
which is not powerful enough to prove[l] as the constructor ( : $: ) 
has values in a type which resides in a higher universe. 

To overcome this limitation, the theory needs to provide a notion of 
weak existential, that is, a £ type without large elimination, which 
would resemble Haskell existentials more faithfully. Although it is 
possible to define weak existentials in an impredicative theory (e.g. 
Coq with —impredicative-set) using a Church encoding, it is 
not clear how to do the same in predicative Martin-Lof type theory. 
Another possible further development of the results in this paper is 
trying to generalize the construction of a free applicative functor 
to endofunctors in any monoidal category. In this more general 
setting, applicative functors correspond to lax monoidal functors, 
and the construction of this paper can be regarded as a left Kan 
extension. 

In fact, suppose C is a monoidal category with unit I and operation 
©, and let / he an endofunctor of C. 

To remove any form of recursion from our definition of FreeA, 
we consider the comonad on the category of monoidal categories 
MonCat corresponding to the adjunction between the forgetful 
functor to Cat and the functor giving the free monoidal category: 
MonCat —> MonCat 

C ^ C* 

with counit e : C* —/ C. 

If we interpret the existential as a coend, we get a very concise 
definition for FreeA f, as the left Kan extension of e o f* along e. 
The result of this paper could then be extended to this more gen¬ 
eral context, and possibly even further, by replacing monoidal cat¬ 
egories with an arbitrary doctrine. 
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